User equipment (UE), also known as mobile terminals, wireless terminals and/or mobile stations are enabled to communicate wirelessly in a wireless communication system, sometimes also referred to as a cellular radio system. The communication may be made e.g. between two user equipment units, between a user equipment and a regular telephone and/or between a user equipment and a server via a Radio Access Network (RAN) and possibly one or more core networks.
The user equipment may further be referred to as mobile telephones, cellular telephones, laptops with wireless capability. The user equipment in the present context may be, for example, portable, pocket-storable, hand-held, computer-comprised, or vehicle-mounted mobile devices, enabled to communicate voice and/or data, via the radio access network, with another entity, such as another user equipment or a server.
The wireless communication system covers a geographical area which is divided into cell areas, with each cell area being served by a base station, e.g. a Radio Base Station (RBS), which in some networks may be referred to as “eNB”, “eNodeB”, “NodeB” or “B node”, depending on the technology and terminology used. The base stations may be of different classes such as e.g. macro eNodeB, home eNodeB or pico base station, based on transmission power and thereby also cell size. A cell is the geographical area where radio coverage is provided by the base station at a base station site. One base station, situated on the base station site, may serve one or several cells. The base stations communicate over the air interface operating on radio frequencies with the mobile stations within range of the base stations.
In 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE), base stations, which may be referred to as eNodeBs or even eNBs, may be connected to a gateway e.g. a radio access gateway. The radio network controllers may be connected to one or more core networks.
Universal Mobile Telecommunications System (UMTS) is a third generation mobile communication system, which evolved from the GSM. GSM is an abbreviation for Global System for Mobile Communications (originally: Groupe Special Mobile). UMTS is intended to provide improved mobile communication services based on Wideband Code Division Multiple Access (WCDMA) access technology. UMTS Terrestrial Radio Access Network (UTRAN) is essentially a radio access network using wideband code division multiple access for mobile stations. The 3GPP has undertaken to evolve further the UTRAN and GSM based radio access network technologies.
In 3GPP, the standardization of the Long Term Evolution (LTE) Release 10 of UTRAN is currently on-going. The new radio access network may also be referred to by the acronym E-UTRAN, Evolved UTRAN.
The Radio Resource Control (RRC) protocol is the signalling protocol responsible for configuring and re-configuring lower layers of the user equipment. These lower layers include the physical layer, Medium Access Control (MAC), Radio Link Control Protocol (RLC), and Packet Data Convergence Protocol (PDCP). The RRC protocol is terminated in the base station and the user equipment, respectively.
One important function of the RRC protocol is to distribute System Information. System Information parameter values are distributed from the base station to all user equipment units in the entire cell. System Information is used to configure parameters that are needed by the whole user equipment population, and parameters in System Information are relevant for both Idle and Connected user equipment units. Typically, System Information may be used for distributing information about the carrier, configuration describing common channels and Random Access parameters, and parameters defining how the user equipment may select or prioritize cells, frequencies and Radio Access Technologies (RATs). Also, the Time Division Duplex (TDD) configuration, describing which of the sub frames are for uplink and which are for downlink as well as parameters related to a special sub frame in Time Division LTE (TD-LTE), such as the guard period, may be signalled using System Information.
TDD is an application of time-division multiplexing to separate uplink and downlink frames in time, possibly with a guard period situated in the time domain between the uplink and downlink frames.
In the present context, the expression downlink is used for the transmission path from the base station to the user equipment. The expression uplink is used for the transmission path in the opposite direction i.e. from the user equipment to the base station.
Parameters for system information distribution are grouped into System Information Blocks (SIBs). Currently, there are fourteen such blocks defined in LTE RRC; a Master Information Block (MIB) and thirteen other SIBs. MIB contains the most essential information of the cell. This MIB is transmitted in a separate System Information Message, which in the present context is referred to as SI-M, that has a fixed time and resource position. SIB1 is also transmitted in separate System Information message 1 (SI-1) and comprises, among other things, information of how other SIBs are mapped into system information messages, and how these system information messages are scheduled. SIB1 has a fixed periodicity such as e.g. 80 milliseconds, with repetitions e.g. every 20 millisecond and position in the time domain (subframe #5 every 2nd radio frame), but the resources are scheduled with Physical Downlink Control Channel (PDCCH).
Other SIBs (except MIB and SIB1) that need to be transmitted with the same periodicity may be mapped into the same System Information message. These System Information messages are dynamically scheduled by regular indications on the PDCCH control channel. A special identity, System Information-Radio Network Temporary Identifier (SI-RNTI), has been defined to identify scheduling of System Information messages from other traffic on Downlink Shared Channel (DL-SCH). A single SI-RNTI is used for scheduling of all System Information messages on Broadcast Control Channel (BCCH).
Not all SIBs are transmitted in every cell. For example, SIB8 contains parameters for inter-working with Code Division Multiple Access 2000 (CDMA2000), and SIB8 is therefore only transmitted in areas and by operators where such inter-working is relevant.
MIB, SIB1 and SIB2 must be present in every cell, and this group of information is therefore denoted “essential system information” in LTE RRC. A user equipment considers the cell as “barred” in case it cannot find this essential system information.
System Information Messages are sent periodically, where the most frequently needed parameter values may be repeated e.g. every 80 millisecond, while parameter values relevant for accessing the cell, such as e.g. random access parameters could be distributed e.g. every 160 milliseconds. Cell-selection parameters may be repeated with a period of e.g. 320 milliseconds. MIB is per definition scheduled every 40 millisecond.
System Information Change
In some cases, there may be a need to update some system information parameters. For this purpose, a method for system information update has been defined; wherein user equipment units are notified of the change and may re-acquire the updated system information.
The notification used to indicate that system information change will happen, must reach both connected (RRC_CONNECTED) and idle (RRC_IDLE) mode user equipment units. This is realized by the use of a “modification period”. System information is changed at the boundary of modification period. The length of the modification period defined as:modification period=modificationPeriodCoeff*defaultPagingCycle,where parameter modificationPeriodCoeff has minimum value of 2 and defaultPagingCycle has minimum value of 32 radio frames. Thus, the shortest possible modification period is 640 milliseconds. Much longer change periods may also be configured, depending e.g. on the desired paging cycle, as may be seen from the equation above.
The parameters defining the modification period are also broadcasted in the cell, in SIB2.
There are two mechanisms to notify the user equipment units of an upcoming system information change. During the modification period prior to the change, user equipment units in IDLE state are reached by means of paging, where paging message comprises an indication that system information may change at the end of modification period.
In addition, SIB1 includes a ValueTag of 5 bits that shall be changed for each change of system information. This value tag shall be changed at the modification border, such that the new system information is associated with a new value in the ValueTag. Thus, a user equipment that identifies a new value on the tag, e.g. after returning from out-of-coverage, will therefore know whether its stored system information is still valid or not. Stored information whose validity has not been verified for 3 hours is considered invalid in the user equipment.
User equipment units in idle mode are required to monitor the paging channel. A detection of a system information change indication in a paging message will guide the user equipment to re-read system information starting at the next modification border. A user equipment in idle mode that has missed some or all its paging opportunities must verify the validity of system information from the aforementioned ValueTag. A user equipment in connected mode may check either paging or the ValueTag at the modification border to verify the validity of its stored system information.
These general principles are illustrated in FIG. 1A, in which different patterns on the blocks representing system information messages indicate different system information content. Upon receiving a change notification, the user equipment knows that the current system information is valid until the next modification period boundary. After this boundary, the user equipment acquires the new system information. There is a period during which the user equipment does not have valid system information. However, the user equipment is allowed to operate with the “old” system information until it has successfully received the updated information.
LTE TDD and the Parameters of TDD in SI
LTE may operate both in Frequency Division Duplex (FDD) or TDD mode. A key difference between TDD and FDD is that for TDD, the same spectrum is shared between uplink and downlink by means of time division. For LTE TDD, this means that the ten 1 millisecond sub frames of a 10 millisecond radio frame are allocated to uplink or downlink, with the so called special sub frames. A special sub frame has duration of 1 millisecond, and it comprises a Downlink part (DwPTS), a Guard Period (GP) as well as an Uplink part (UpPTS). This is shown in FIG. 1B.
The guard period is utilized to separate uplink and downlink in the user equipment units and the base stations in the presence of propagation delays, and also for allowing the involved user equipment units and the base stations to switch between receiving and transmitting mode. The guard period is typically chosen to match the largest round trip propagation delay in the cell plus the switching time between receiving and transmitting mode of the nodes in the system. The size of the guard period may also be chosen to avoid interference from remote base stations which due to propagation delays are still in the air when the uplink begins, despite the fact that all base stations have ceased transmission at the same time in a synchronized network.
There are currently seven uplink-downlink configurations and nine configurations of the special sub frames. The configurations are illustrated in FIG. 1C and FIG. 1D.
For LTE TDD, the uplink/downlink as well as special sub frame configurations are transmitted in SIB1 as the parameter TDD-Config. Based on this parameter, user equipment units will determine a large number of other settings, such as timing of uplink and downlink control signalling, sounding as well as Random Access Channel (RACH).
From an operator perspective, the TDD spectrum asset offers a potential to select uplink and downlink resource configuration depending on the deployment and services offered. A more symmetric configuration may be chosen for symmetric services such as Voice over Internet Protocol (VoIP), whereas a downlink heavy configuration may be suitable for multimedia distribution such as mobile television and web browsing producing typically more data for downlink direction.
TDD systems built for wide area coverage, also known as macro base stations, typically tend to use the same TDD-config in all cells within the wireless communication system. This way interference between uplink and downlink is avoided. At the same time, for other deployments, such as femto, pico or micro base stations, these requirements may be relaxed, especially for the case with low to medium load. One reason being that the propagation conditions are expected to very different between base stations as well as the transmission powers. An important scenario is femto base stations, which may be user deployed for example in home environments, and where the number of user equipment units served by each base station is small, and where the isolation between different base stations may be large in combination with low output powers.
A difference of packet data as compared to voice services is that it is bursty, on-off and asymmetric. During file download phase, the downlink traffic is dominating whereas during upload phase, the uplink traffic will dominate. Furthermore, Transmission Control Protocol (TCP), being the dominating transport protocol on the Internet, is elastic in its nature. The TCP source probes the available bandwidth of the network. Because of this, the offered load does not stay constant over the download/upload procedure.
To maximize the efficiency and more importantly improve the user experience in terms of file transfer time and latency, it is desirable to adapt the resource allocation to the actual resource needs in up- and downlink, respectively. Obviously, performance benefits are achievable by adapting the resources to the actual load in uplink and downlink as compared to using a fixed allocation. Furthermore, to be able to follow rapid variations in the resource need, which are expected in packet data applications, a dynamic and efficient mechanism is needed so that the TDD-config may be updated efficiently and quickly.
Another important case where there is a need to adapt the TDD-config is the case with interference between base stations separated large distances. Due to atmospheric propagation phenomena, the isolation between base stations may vary, and at certain occasions, base stations at very large distances may be heard by each other for a limited amount of time. It is inefficient to dimension a large guard period and use it all times, despite that a large guard period is only needed a small fraction at a time. From this perspective, an efficient and rather rapid mechanism to change the TDD-Config is desirable.
There are also other parameters carried in system information that may need frequent updates. One is Random Access Channel (RACH) configuration used to determine the resources, time and frequency, for random access attempt. It may be expected that the amount of user equipments, and/or other devices communicating over a wireless interface in the wireless communication system will increase significantly in future when different kind of Machine-to-Machine (M2M) applications will become popular. In this case, the RACH may be a bottleneck of the system and thus the network needs dimension RACH allocation adaptively.
A third motivator for rapid system information changes may be the desire to save power in the base station. At times of low or non-existent load in a cell, the base station may want to adjust certain parameters of the cell, such that electrical power may be saved.
Thus, there are situations when there is a need to change values of system information parameters. A particular, but non-limiting example concerns the dynamic-TDD case above, where there may be a desire to dynamically change system information parameters rather frequently. In particular, it may be noted that in dynamic-TDD, it may be a desire to change system information parameters, even as often as once every second, or even more frequently. A third non-limiting example concerns energy efficiency in the base station, where e.g. the number of used antenna ports, carrier bandwidth or alike could be changed.
As will be further described below, the previously known method for system information change is too time consuming, inefficient and inapplicable.
First, in prior art, the system InfoValueTag may be incremented when the system info is changed. Since systemInfoValueTag has 32 values in LTE RRC, this means that system information may be changed only 31 times in 3 hours resulting the minimum average validity period of 5.6 minutes for each set of system information parameters. Some changes of parameters could hypothetically occur faster, however with the expense that other sets of parameters would then have to be valid for a longer period. In any case, the value tag of 5 bits together with the 3 hour validity does not allow for very frequent system information changes.
If a value tag would be reused for two different sets of system information parameters within 3 hours, there is a risk that a user equipment uses the wrong set of parameters in its communication with the wireless communication system. Depending on the mismatch the consequences could be arbitrarily severe.
Validity times in the order of minutes rather than seconds may for some parameters be too long, i.e. there it is a need to change the parameters more dynamically. Such parameters may comprise, but are not limited to, e.g. RACH parameters or TDD configuration.
Further the user equipment is instructed to read the whole system information if the systemInfoValueTag has changed from a previous value.
As a further issue, it is to be noted that there is a period after the modification border during which the user equipment may have the wrong system information parameters. If system information is changed rarely, e.g. once in an hour or so, the relative time during which the user equipment uses wrong values may not be that detrimental. However, if the periodicity of the message containing the relevant parameters is e.g. 320 milliseconds, then this period is not negligible if the parameter change period is counted in seconds rather than hours.
As a non-limiting example, due to changes in traffic load, the network may want to change TDD configuration. Another possibility is that due to interference, e.g. temporary interference between uplink and downlink (base station-to-base station or UE-to-UE), the TDD guard period (GP) between uplink and downlink needs to be increased, or perhaps decreased due to the absence of such interference. As mentioned above, this avoids operating the system at all with an un-necessarily large guard period.
The corresponding TDD parameters are in in SIB1 having 7 different values for uplink/downlink configuration and 9 values for the special sub frame configuration including length of the guard period. Reading all system information blocks take time, which in turn makes the period when the user equipment have wrong system information long. Also reading the whole system information consumes the batteries of the user equipment.
Therefore, and with the TDD configuration change as a non-limiting example, the user equipment may operate with the wrong configuration until it has re-read SIB1, wherein the user equipment re-read all other system information, even if that system information has not changed.
Further, there is no method to quickly inform the user equipment that it should change the parameter values in its configuration. It may be that the base station detects that the user equipment has e.g. wrong TDD configuration.
One existing way to inform the user equipment about correct configuration is to send RRCConnectionReconfiguration with mobilityControl field, i.e. to perform an “intra-Cell handover”. This operation will result the user equipment to receive updated system information parameters. However, this handover (back) to the current cell results in some procedures such as Random Access and/or reset of RLC, Packet Data Convergence Protocol (PDCP) and MAC which may be unnecessary. Furthermore, the user equipment needs to be in connected state for enabling the reconfiguration.
The current method of notifying user equipment units of an upcoming change is also rather costly in terms of radio resources, in case the changes occur frequently. This is particularly true since every paging slot needs to be used for sending the indication carried in a Paging message, during the change period prior to the change. In addition, paging all user equipment units often, such as e.g. every modification period, consume resources that could be otherwise used for data transmission.
Therefore, there is a need for a new method for system information change, where it is possible to quickly set values of system information parameters without the aforementioned problems occurring. In particular, there is a need for a solution where system information may be changed as often as e.g. once a second or even more frequently without running into the aforementioned problems.